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Art Unit: 2135 

1. Claims 1-18 have been examined. 
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Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

3. Claims 1 and 10 are rejected under 35 U.S.C. 102(b) as anticipated by or, in the 
alternative, under 35 U.S.C. 103(a) as obvious over RFC 2058 ("Remote Authentication 
Dial In User Service (RADIUS)", published January 1997), and as appropriate in view of 
Tianen et al. (PCT Patent WO 99/37055). 

Regarding claims 1 and 10, RFC 2058 teaches an authentication mechanism to 
allow users to connect to the Internet. It teaches a network access server and one or 
more authentication servers (RFC 2058, page 3, "Client/Server Model"). Note that in at 
least one embodiment of RADIUS, one RADIUS server can transfer user authentication 
requests to another RADIUS server when a predetermined condition is met (RFC 2058, 
page 5, "The RADIUS server MAY make requests..."). The authentication server that 
makes the decision has a database associated with it (RFC 2058, page 5, "...the 
RADIUS server consults a database of users..."). The decision is relayed back to the 
network access server, via any intermediary RADIUS servers as necessary (RFC 2058, 
page 7, "The server then sends back..." and page 5, "The RADIUS server MAY make 
requests... in which case it then acts as a client."). The network access server then acts 



Application/Control Number: 09/844,049 Page 3 

Art Unit: 2135 

based upon the result returned by the servers (RFC 2058, page 3, "A Network Access 
Server (N AS)... acting on the response which is returned."). 

Although RFC 2058 is silent regarding the ownership of the servers involved in 
the system, it is considered to be inherently true of RADIUS servers that the ownership 
has no effect on the functionality of properly configured servers, and therefore the 
servers being owned by separate enterprises is immaterial. In the event that Applicant 
challenges this view, it can be shown to be an obvious development in view of the 
Tianen patent. Tianen teaches a system for providing remote access for a plurality of 
host computer networks and their respective authorized users by means of a network 
access server operated by a third party service provider (Tianen, "Abstract" and also 
page 2, lines 13-1 5). Note that the network access server as disclosed by Tianen 
performs the same function as the authentication server disclosed by both RFC 2058 
and Applicant (Tianen, page 7, lines 14-16). Therefore, it would have been obvious to 
one of ordinary skill in the art at the time the invention was made to establish that at 
least one authentication server used in an implementation of RFC 2058 could be owned 
by a third party enterprise, different from the owner of the first authentication server. 
Tianen further teaches that a motivation for having a third party perform authentications 
is to reduce the infrastructure and overhead burden on individual organizations, which is 
beneficial particularly when the organization providing the desired product or service is 
too small to provide its own authentication service (Tianen, page 1 , lines 21-23 and also 
page 2, lines 9-12). 
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Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

5. Claims 2 and 1 1 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 2058 [and Tianen] as applied to claims 1 and 10 above, and further in view of the 
article "Alternate Names Used for Addressing in OfficeVision/2" (IBM Technical 
Disclosure Bulletin Volume 35, Issue 6; henceforth "IBM"). 

Regarding claims 2 and 1 1 , note that RFC 2058 teaches that authentication 
requests contain a user-name, which is a code for specifying a user (RFC 2058, page 
20, "5.1 User-Name"), and also a proxy-state code which, when present, indicates that a 
RADIUS server should forward the request to a different authentication server (RFC 
2058, page 48, "5.33 Proxy-State"). Note that the proxy-state code is not a component 
of the user name, but a separate field in the authentication request. However, IBM 
teaches a software product which had the capacity to resolve a username into a 
bipartite code containing a user id and a node id (IBM, lines 1-4 of the disclosure text). 
In particular, the node id can be construed as a predetermined code, and it is clearly 
contained within the body of the user name, a.k.a. the account code. This reference is 
deemed analogous art as both it and the instant application pertain to account code 
management. Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to permit the use of a predetermined code, similar to a 
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node id from the IBM disclosure, as part of the username required by the RADIUS 
authentication system, and to set the proxy-state field of the authentication request to 
forward it to another RADIUS server if said code is detected within the username. By 
doing so, one can use the same authentication hardware to authenticate and distinguish 
between multiple services without requiring significant upgrades. 

6. Claims 4 and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 2058 [and Tianen] as applied to claims 1 and 10 above, and further in view of 
Nguyen et al. (U.S. Patent 6,006,334). 

Regarding claims 4 and 13, neither RFC 2058 nor Tianen teach a lobby server 
for providing a chance to find a negotiation partner among a plurality of users on the 
Internet as the server for which access needs to be granted. However, Nguyen teaches 
that at the time of the invention Blizzard Entertainment Inc. had already established a 
computer game matchmaking service called Battle. Net™, comprising one or more lobby 
servers where players of the computer game Diablo™ could meet online and play with 
each other (Nguyen, column 1 , lines 31-36). Therefore, it would have been obvious to 
one of ordinary skill in the art at the time the invention was made to use the access 
control method of RFC 2058 as the authentication method for access to a lobby server 
such as the Battle. Net™ service taught by Nguyen. With a proper authentication 
scheme in place, one can more easily verify that the only users allowed on the lobby 
server are those who have legitimately purchased a copy of the game or computer 
program that one desires to use online (Nguyen, column 1 , lines 36-41 ). 



Application/Control Number: 09/844,049 Page 6 

Art Unit: 2135 

7. Claims 3 and 12 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
the combination of RFC 2058, [Tianen], and IBM as applied to claims 2 and 1 1 above, 
and further in view of Nguyen (U.S. Patent 6,006,334) and also in view of the instruction 
manual for the computer game Starcraft™ (©1998 Blizzard Entertainment). 

Regarding claims 3 and 12, again note the lobby server and the services it 
provides as found in the text of the Nguyen patent (Nguyen, column 1, lines 31-36). In 
addition, it must be noted that in order to utilize the predetermined services offered by 
Battle.Net™, one must log in with a Battle.Net ID (Starcraft manual, page 8, "Battle.Net 
requires the creation of a separate Battle.Net ID."). Therefore, it would have been 
obvious to one of ordinary skill in the art at the time the invention was made to use a 
username containing a predetermined code, such as the one found in the teachings of 
RFC 2058 as modified by IBM [and Tianen]), as the account code for utilizing a 
predetermined service on a server provided by a second enterprise (for example, as the 
Battle.Net ID for use on Battle.Net, as disclosed by Nguyen and the Starcraft manual). 
Doing so would simplify administrative duties for the enterprise hosting the servers 
featuring the predetermined service, as the alternative would be to require a separate 
set of account codes on the authentication server distinct from those recognized by the 
servers providing a predetermined service, and correlating the two sets of account 
codes would require considerable effort. 

8. Claims 5 and 14 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 2058 [and Tianen] as applied to claims 1 and 10 above, and further in view of RFC 
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2059 ("Radius Accounting", published January 1997) and also Peterson et al. (U.S. 
Patent 6,349,289). 

Regarding claims 5 and 14, RFC 2058 does not teach detecting devices that can 
track a user's history of connecting to the Internet, nor track a user's history of utilizing a 
service from a server. However, the companion document RFC 2059 teaches 
additional functionality, in the form of Radius Accounting servers, that work in 
conjunction with Radius authentication servers to track accounting information (RFC 
2059, page 2, "Introduction", 2 nd paragraph). Of particular interest is the capability for 
Radius to generate a record of the type of service provided and the duration (RFC 2059, 
pages 3-4, "Operation", 1 st paragraph). Such information would constitute a history of 
service utilization; further, since the service being rendered necessarily requires one to 
be connected to the Internet, this record also constitutes a history of Internet usage as 
well. It can also be said that any server that keeps track of such accounting information 
can be construed to be a detecting device. Therefore, it would have been obvious to 
one of ordinary skill in the art at the time the invention was made to implement the 
Radius accounting features described in RFC 2059 into the Radius authorization 
system described in the rejection of claims 1 and 10. It is clear from the cited 
references that the two Radius components were designed from the outset to 
interoperate, and that its inventors encouraged this practice. Even were that not so, 
adding an accounting feature to an authentication system would give the administrators 
the beneficial ability to audit the access records, in order to verify the proper functioning 
of the authentication system. 



Application/Control Number: 09/844,049 Page 8 

Art Unit: 2135 

Further regarding claims 5 and 14, neither RFC document teaches the use of an 
account-information generating device that is capable of assessing an access charge to 
the user based on the usage history observed by detection devices. However, Tianen 
teaches a method for tracking computer system usage through a remote access 
security device, which includes a billing server that is capable of assessing service fees 
for the use of a target computer network (Peterson, column 2, lines 50-60). Further, a 
billing application is run that gathers the necessary billing information by communicating 
with both the ESS server and a network access server (Peterson, column 3, lines 13- 
1 7). It should again be noted that the network access server disclosed by Peterson 
performs the equivalent function of the authentication servers disclosed by both 
Applicant and the RFC documents. Therefore, it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to incorporate the billing 
mechanism disclosed in Peterson into a Radius system as taught by RFC 2058, 
modified to include accounting functionality as per RFC 2059. Billing a user based on 
one's usage history could be seen as a more efficient alternative to billing for a service 
with a flat fee per month, particularly when a large number of users make frequent use 
of the service being offered. 

9. Claims 6-8 and 15-17 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over the combination of RFC 2058, RFC 2059, [Tianen], and Peterson as applied to 
claims 5 and 14 above, and further in view of Deaton et al. (U.S. Patent 6,61 1 ,81 1 ). 
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Regarding claims 6 and 15, none of the previously cited references teach that a 
discount condition can be applied by an accounting information generating device. Note 
that it is understood that a discount condition by definition would mean that the charge 
for a product or service would be less when the condition is applied than it would be 
were the discount not applied. Furthermore, Deaton teaches a method by which 
discounts can be applied to items purchased on the Internet (Deaton, column 1, line 66 
- column 2, line 13). Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to allow the accounting information 
generating device as found in the combination of RFC 2058, Peterson, and Tianen to 
permit discounts on the products being sold or services being rendered by the second 
enterprise. As Deaton teaches, providing discounts is likely to induce users into 
continuing to use the offered services or to purchase additional products from the 
enterprise offering said discounts (Deaton, column 2, lines 22-24). 

Regarding claims 7, 8, 16, and 17, nothing in the combination of references 
above teach that the discount condition above could be based on the user exceeding a 
predetermined amount of money in one's purchases of the product or service sold by 
the second enterprise. However, Deaton teaches a method by which discounts can be 
applied, both on individual items in an order and on the order as a whole, when the 
cumulative price of the order exceeds a predefined threshold (Deaton, column 1, lines 
53-65). Also, note that it is clearly the case that the user must be actively purchasing 
items from the seller for the discount to be applied; ergo the predetermined discount 
condition found in Deaton is associated with utilization of the user relevant to the service 
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provided by the enterprise. Therefore, it would have been obvious to one of ordinary 
skill in the art at the time the invention was made to define a threshold for a user's 
purchases of a product or service, such that a discount condition could be applied if the 
charge to the user exceeds said threshold. Offering discount incentives to a user in this 
fashion is preferable because it provides the appearance that a customer's desired 
products are on sale, which in turn induces said customer into future purchases from 
that seller (Deaton, column 2, lines 15-24). 

10. Claims 9 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
the combination of RFC 2058, RFC 2059, Peterson, [Tianen], and Deaton as applied to 
claims 7 and 16 above, and further in view of Acres (U.S. Patent 6,565,434). 

Regarding claims 9 and 18, none of the preceding combination of references 
teach a game as the service provided by the server, nor that a discount condition can 
be applied if a certain game state is reached. However, Acres teaches a networked 
gaming system controlled by a server that is capable of awarding prizes and bonuses to 
players (Acres, Figure 5 and column 17, lines 27-34). Of particular relevance is the 
Welcome Back bonus, which can be earned by players who have acquired a requisite 
number of points through playing the games; the Welcome Back bonus in one 
embodiment of the system is a half-price discount (Acres, column 1 1 , lines 8-12). 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to establish that the server protected by the authentication 
mechanism disclosed by the combination of RFCs 2058 and 2059, [Tianen], Peterson, 
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and Deaton should be a pay-for-play game server, and further for said server to reward 
players with a discount based on the user's performance in said game. Rewarding 
players with occasional bonuses and discounts serves to induce the players to continue 
playing in the hopes of winning further, thus ultimately providing the owner of the server 
with increased revenue. 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tom Gyorfi whose telephone number is (571) 272-3849. 
The examiner can normally be reached on 8:00am - 4:30pm Monday - Friday. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kim Vu can be reached on (571) 272-3859. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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